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(57) Abstract: In accordance with one embodiment of the present invention, a network element comprises a first subsystem operable 
to receive management transactions in a first management protocol and to map the transactions to a common management protocol. 
A second subsystem is operable to receive management transactions in a second management protocol and to map the transactions 
to the common management protocol. A common management information base (MLB) includes a dataset and a common interface 
to the dataset. The common interface is operable to access the dataset to process transactions received from the first and second 
subsystems in the common management protocol. 
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NETWORK MANAGEMENT 



TECHNICAL FIELD OF THE INVENTION 

This invention relates generally to telecommunications 
systems , and more particularly to a method and system for 
managing multiple management protocols in a network 
5 element . 

BACKGROUND OF THE INVENTION 

Telecommunications systems include customer premise 
equipment (CPE) , local loops connecting each customer 

10 premise to a central office (CO) or other node, nodes 

providing switching and signaling for the system, and 
internode trunks connecting the various nodes. The 
customer premise equipment (CPE) includes telephones, 
modems for communicating data over phone lines, computer 

15 and other devices that can directly communicate video, 

audio, and other data over a datalink. The network nodes 
include tradition circuit -switch nodes, which have 
transmission pass dedicated to specific users for the 
duration of a call and employ continuous, fixed-bandwidth 

20 transmission as well as packet-switch nodes that allow 

dynamic bandwidth, dependent on the application. The 
transmission media between the nodes may be wireline, 
wireless, or a combination of these or other transmission 
medias . 

2 5 In a telecommunication system, the nodes are managed 

by standardized management protocols such as Transaction 
Language One (TL-1) , simple network management protocol 
(SNMP) , Common Management Information Service Element 
(CMISE) , and the like. Generally speaking, each of these 

3 0 management protocols includes a protocol agent and object 

model . The agent is responsible for parsing the external 
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management commands and maintaining communication sessions 
with external management stations or users. The object 
model is a management information base (MIB) . The MIB is 
a data structure built for a specific management protocol 
5 to exchange the management information between a node and 

external management stations. 

Multiple protocol nodes that handle disparate types of 
traffic are typically required to support multiple 
management protocols such as TL-1, SNMP, and/or CMISE. 

10 Provision of multiple databases to support the different 

protocols requires large amounts of resources to implement 
the databases and maintain data integrity across the 
databases. One attempt to use a single database for 
multiple protocols configured the database in accordance 

15 with one protocol and used a protocol adapter for a second 

protocol . The protocol adapter translates protocol 
messages from the second protocol to the first protocol and 
responses back to the second protocol . Due to the 
incompatibility between management protocols, however, the 

2 0 adapter is a complex component that is expensive to 

implement. In addition, the adapter is inefficient due to 
the protocol translations, which slow down response time. 
Other attempts to support multiple management protocols 
with a single database provided only limited functionality 

25 for one of the protocols while creating special commands 

for the other. This solution is expensive to implement and 
provides only a partial solution. 

SUMMARY OF THE INVENTION 

30 The present invention provides a method and system for 

managing multiple management protocols in a network element 
that substantially eliminates or reduces problems 
associated with previous methods and systems. In 
particular, the common MIB provides a layer of abstraction 

35 to isolate internal data representations from data 
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representations made externally to a network element. This 
allows a network element to have a single, consistent 
internal representation of data, and at the same time, 
support multiple different external interfaces for 
5 management . 

In accordance with one embodiment of the present 
invention, a network element comprises a first subsystem 
operable to receive management transactions in a first 
management protocol and to map the transactions ' to a common 

10 management protocol. A second subsystem is operable to 

receive management transactions in a second management 
protocol and to map the transactions to the common 
management protocol. A common management information base 
(MIB) includes a dataset and a common interface to the 

15 dataset . The common interface is operable to access the 

dataset to process transactions received from the first and 
second subsystems in the common management protocol . 

Technical advantages of the present invention include 
providing a protocol independent MIB for managing multi- 

20 protocol network elements within a telecommunications 

network. In particular, the common MIB provides a layer of 
abstraction to isolate data representations internal to the 
network element from data representations made externally 
to the network element. This allows the network element to 

25 have a single, consistent internal representation of data 

and at the same time support multiple different external 
interfaces for management. As a result, data integrity and 
consistency is guaranteed as only a single database is 
maintained . 

3 0 To support multiple external data representations, the 

network element performs transformations to convert the 
data between the internal representation and the required 
external representation format. Thus, adaptation functions 
between management protocols is eliminated and each 

3 5 management protocol is capable to support complete 
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management of the network element. Moreover, the modular 
design of the common MIB allows for time and cost efficient 
testing, integration and packaging of the system. 

Other technical advantages of the present invention 
5 will be readily apparent to one skilled in the art from the 

following figures, description, and claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present 
10 invention and its advantages, reference is now made to the 

following description taken in conjunction with the 
accompanying drawings, wherein like reference numerals 
represent like parts, in which: 

FIGURE 1 is a block diagram illustrating a common 
15 management information base (MIB) in accordance with one 

embodiment of the present invention; 

FIGURE 2 is a block diagram illustrating relationships 
between interface, base and managed entities (ME) classes 
in the common MIB of FIGURE 1 in accordance with one 
20 embodiment of the present invention; 

FIGURE 3 is a block diagram illustrating the ME 
command object of FIGURE 1 in accordance with one 
embodiment of the present invention; and 

FIGURE 4 is a flow diagram illustrating a method for 
2 5 performing a management transaction with the common MIB of 

FIGURE 1 in accordance with one embodiment of the present 
invention. 

DETAILED DESCRIPTION OF THE INVENTION 

30 FIGURE 1 illustrates management components of a multi- 

protocol network element (NE) 10 in accordance " with one 
embodiment of the present invention. In this embodiment, 
the NE 10 includes Internet Protocol (IP) , Asynchronous 
Transfer Mode (ATM) , and . Synchronous Optical Network 

35 (SONET) layers and functionality and can communicate over 
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local area networks (LANs) as well as transmission line 
trunks. IP and other suitable traffic from the LAN is 
converted to ATM traffic for transmission by the SONET 
layer which forms the physical interface for the 
5 transmission line trunks. 

The NE 10 supports Common Management Information 
Service Element (CMISE) , simple network management protocol 
(SNMP) , and Transaction Language One (TL-1) management 
protocols. A CMISE management station 14, SNMP management 
10 station 16, and TL-1 management station 18 are coupled to 

the NE 10 by a local area network (LAN) , wide area network 
(WAN) , or other communication link 20. Accordingly, the 
management stations 14, 16, and 18 may be local or remote 
from the NE 10. 

15 Referring to FIGURE 1, the NE 10 includes a plurality 

of protocol -specific subsystems 30, a common management 
information base (MIB) 32, and a set of low level software 
drivers 34. Each subsystem 30 includes a protocol -specif ic 
agent 40 and a data model 42. The protocol- specif ic agent 

2 0 4 0 parses external management commands and maintains 

communication sessions with external management stations or 
users. The data model 42 maps protocol -specif ic management 
transactions received from a management station to a common 
management protocol for processing by the common MIB 32. 

25 Accordingly, all protocol -specif ic processing is local to 

the subsystems 30, allowing the common MIB 32 to be 
protocol independent . 

For the embodiment of FIGURE 1, the subsystems 30 
include a CMISE subsystem 50 for supporting the CMISE 

30 management station 14, a SNMP subsystem 52 for supporting 

the SNMP subsystem 16, and a TL-1 subsystem 54 for 
supporting the TL-1 management station 18. The CMISE 

protocol is an OSI defined management service containing an 
interface with a user, specifying the service provided, and 

35 a protocol, specifying the protocol data unit format and 
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the associated procedures. In the CMISE subsystem 50, the 
data model 42 is a Guideline for Definition of Managed 
Object (GDMO) which is an OSI specification for defining a 
management information structure used in the CMISE 
environment. SNMP is an IETF defined network management 
protocol including definitions of a database and associated 
concepts. In the SNMP subsystem 52, the data model 42 is 
an entity- relationship model in accordance with SNMP 
standards. TL-1 is an ASCII or man-machine management 
protocol defined by Bellcore and typically used to manage 
broadband and access equipment in North America. In the 
TL-1 subsystem 54, the data model 42 includes a data 
dictionary for access identifiers (AIDs) and commands in 
accordance with TL-1 standards. In this way, the data 
15 models 42 only occupy a small amount of memory resources in 

the network element 10 and keep protocol -specif ic 
processing local to each subsystem 50, 52, or 54. 

The common MIB 32 includes an application interface 
(API) 60, a transaction queue 62, a set of response queues 
20 64 / and a database 66. The API 60 provides generic 

management functionality to the CMISE, SNMP, and TL-1 
subsystems 50, 52, and 54. As described in more detail 
below, the common MIB 32 provides an efficient and flexible 
component to allow a telecommunications device to be 
2 5 controlled and monitored by external interfaces using 

specific management protocols. 

The API 60 includes an interface object 70 for each 
subsystem 30 registered with the API 60, one or more 
command objects 72 for each registered subsystem 30, and a 
set of managed entity (ME) classes 74 to which protocol - 
specific transactions are mapped by the subsystems 30. As 
described in more detail below, by applying object-oriented 
modeling techniques, the information of the hardware and/or 
software resource is encapsulated into the class 



30 
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definition, which then provides service interfaces to other 
software components . 

The interface objects 70 are each accessed by a 
corresponding subsystem 30 to communicate with the API 60. 
5 The interface object 70 for a subsystem 30 is created by 

the API 60 upon registration by the subsystem 30. At that 
time, the subsystem 3 0 requests a number of command objects 
72 that can be simultaneously used by the subsystem 30, 
which are generated and allocated by the API 60. 

10 The command objects 72 each encapsulate a base class 

76 for the ME classes 74. The ME classes 74 each include 
specific functionality for an ME type. The base class 76 
includes function calls, methods, parameters, behaviors, 
and other attributes shared by all or at least some of the 

15 ME classes 74. Accordingly, each command object 12 

includes base functionality that is used by the ME classes 
74 to access the database 66 or perform functions within 
the common MIB 32, such as communicating with the low level 
software driver 3 4 in order to determine or change the 

20 state of hardware in the NE 10. As described in more 

detail below, portions of the base class 76 may be 
overloaded by specific ME classes 74 when forming an ME 
command object 78. The ME command object 78 forms an 
interface for accessing ME attributes and functions in the 

25 database 66 and the low level software driver 34. In this 

way, each ME class 74 may select functionality from the 
base class 76 to be used in accessing the corresponding ME. 

The transaction queue 62 stores ME command objects 78 
generated by the API 60 in conjunction with the subsystems 

30 30 for processing by the common MIB 32. In one embodiment, 

the transaction queue 32 is a first-in-first-out (FIFO) 
buffer that serializes processing in the common MIB 32 to 
prevent multiple operations from being performed at the 
same time, and thus prevent corruption of data, data 

35 contention, and race conditions within the common MIB 32. 
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In the database 66, attributes for each of the ME 
types are stored in ME data structures 80. Preferably, the 
data structures are non-volatile structures to ensure data 
integrity. In one embodiment, the database 66 is a 
5 relational database and the ME data structures 80 are 

relational database tables. It will be understood that the 
ME attributes may be otherwise suitably stored without 
departing from the scope of the present invention. 

The response queues 64 store responses to transactions 

10 processed by the common MIB 32. In one embodiment, the 

response queues 64 include a discrete queue for each 
subsystem 30. In this embodiment, each subsystem 3 0 reads 
responses in its corresponding queue 64 and extracts data 
for generating a protocol -specif ic response for 

15 transmission to the management station originating the 

transaction. It will be understood that responses to 
transactions may be otherwise made available by the common 
MIB 32 to the subsystems 30. 

FIGURE 2 illustrates details of the object interfaces 

2 0 70, command objects 72, and ME class objects 74 in 

accordance with one embodiment of the present invention. 
In this embodiment, the objects 70, 72, and 74 are each 
fully instantiated objects encapsulating both data and 
behavior and inheriting data and behavior from parent 

25 classes. 

Referring to FIGURE 2, the interface object 70 
includes client callback, client quality of service (QoS) , 
client command objects, and client interface parameters. 
The interface object 70 calls an associated command object 

30 72 in the API 60. 

The command objects 72 include command methods, 
command correlation, command errors, and command 
parameters. The command object 72 further inherits 
attributes of the base class 76.. As previously described, 
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the base class 7 6 includes common ME attributes and common 
ME methods . 

The ME class objects 74 each include functionality 
associated with a particular ME type. Such functionality 
5 includes ME attributes, methods, parameters, and behavior 

for the ME type. Attributes of an ME class 74 are 
inherited by the command objects 72 through the base class 
76 to generate the ME command object 78. As previously 
described, the ME command object 78 provides an interface 

10 for accessing data and functionality in the common MIB 32. 

FIGURE 3 illustrates details of an ME command object 
78 in accordance with one embodiment of the present 
invention. In this embodiment, the ME command object 78 is 
self contained. Any system resources obtained, such as 

15 memory or buffers are "owned" by the object 78 and released 

when the object 78 is destructed. It will be understood 
that the ME command object 78 may be otherwise suitably 
implemented for accessing data and attributes and common 
MIB 32. 

2 0 Referring to FIGURE 3, the ME command object 78- 

includes a public data section 100 and a private data 
section 102. The public data section 100 of the ME command 
object 78 is accessible by the client subsystem 30. The 
public data section 100 includes method functions that hide 

2 5 the structure, data manipulation, and allocation details 

from the client subsystem 30. In addition, the methods in 
the public data section 100 respond to affects of the 
methods chosen and perform any command integrity checks 
required. 

3 0 In one embodiment, the methods may include inline 

functions, particularly those used for setting and 
retrieving small (typically integer) attribute values. 
Attribute methods, for example, will be available to 
populate get/set/create commands, and to retrieve values 
35 resulting from the same. Constructor, invoker, and 
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releasor methods will be used to create, execute,, and 
destroy ME command objects 78. Behavior methods are used 
by common MIB 32 to execute the commands. 

The private data section 102 of the ME command object 
5 78 includes data to complete the command. The response 

data for successful or error return will also be contained 
in the private data section 102. In one embodiment, any 
miscellaneous system resources dynamically allocated for 
the command are retained in the private data section 102. 
10 This type of allocation is preferably minimized. 

FIGURE 4 is a flow diagram illustrating a method for 
performing a management transaction in accordance with one 
embodiment of the present invention. In this embodiment, 
the transaction may be received from any one of the 
15 plurality of management stations in a management protocol 

supported by the NE 10. 

Referring to FIGURE 4, the method begins at step 110 
in which subsystem 30 receives a transaction in a specific 
management protocol. Next, at step 112, the subsystem 3 0 

2 0 maps the protocol specific transaction to a protocol 

independent ME class 74 which will be used by the common 
MIB 3 2 to perform the transaction. Mapping may include any 
suitable type of transaction, conversion, or associations. 
Accordingly, protocol specific processing is retained at 

25 the subsystem level. 

At step 114, the subsystem 30 opens a communications 
session with the API 60. As previously described, the 
session may be opened by calling an interface object 70 in 
the API 60 corresponding to the subsystem 30. Proceeding 

30 to step 116, the subsystem 3 0 requests a command object 72 

from the API 60. The subsystem 30 may use any number of 
command object 72 at a time up to the number allocated to 
the subsystem 3 0 in the API 60. 

At step 118, the subsystem 3 0 identifies the protocol 

3 5 independent ME class 74 to which the protocol specific 
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transaction was mapped. Next, at step 12 0, the API 60 
generates and returns an ME command object 70 to the 
subsystem 30. As previously described, the ME command 
object 78 includes attributes of the base class 76 and the 
5 ME class 74. Portions of the ME class 74 may overload 

portions of the base class 76 to provide specific 
functionality in place of base functionality. At step 122, 
the subsystem 3 0 populates the ME command object 78 based 
on the transaction by calling command functions stored in 

10 the ME command object 78. 

Proceeding to step 124, the populated ME command 
object 78 is transferred to the transaction queue 62 in 
common MIB 32 for processing. The transaction queue 32 
serializes processing in common MIB 32 to prevent data 

15 contention between co-pending ME command objects 78. At 

step 12 6, the ME command object 78 is removed from the 
transaction queue 62 and executed by the common MIB 32. 
During execution, the ME command object 7 8 accesses the 
corresponding ME table 8 0 and/or performs functions in 

20 accordance with functions, behaviors, and parameters in the 

ME command object 7 8 which are based on the transaction. 

Next, at step 128, the common MIB 32 generates a 
response in accordance with the function calls in the ME 
command object 78. At step 130, the response is 

25 transferred to the response queue 64 for the subsystem 3 0 

that generated the ME command object 78. Next, at step 
132, the subsystem 3 0 extracts data from the response and 
generates a protocol specific response for transfer back to 
the requesting management station. At step 134, the 

3 0 subsystem 3 0 releases the command object 72 back to the API 

60. In this way, the common MIB 32 provides a layer of 
abstraction to isolate data representations internal to the 
network element 10 from data representations made 
externally to the network element 10. Data integrity and 
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consistency is guaranteed as only a single database is 
maintained. 

Although the present invention has been described with 
several embodiments, various changes and modifications may 
be suggested to one skilled in the art. It is intended 
that the present invention encompass such changes and 
modifications as fall within the scope of the appended 
claims . 
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WHAT IS CLAIMED IS: 

1. A network element, comprising: 

a first subsystem operable to receive management 
transactions in a first management protocol and to map the 
5 management transactions to a common management protocol; 

a second subsystem operable to receive management 
transactions in a second management protocol and to map the 
second transactions to the common management protocol; and 

a common management information base (MIB) comprising 
10 a dataset and a common interface to the dataset, the 

interface comprising software stored in. a computer -readable 
medium and operable to access the dataset to process 
transactions from the first and second subsystems in the 
common management protocol . 

15 

2. The network element. of Claim 1, further 
comprising: 

a third subsystem operable to receive management 
transactions in a third management protocol and to map the 
20 transactions to the common management protocol; and 

the common interface operable to access the dataset to 
process transactions received from the third subsystem in 
the common management protocol . 

25 3. The network element of Claim 1, further 

comprising the first subsystem operable to receive 
management transactions in a Common Management Information 
Service Element (CMISE) protocol and to map the transaction 
to the common management protocol . 
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4. The network element of Claim 1, further 
comprising the first subsystem operable to receive 
management transactions in a simple network management 
protocol (SNMP) and to map the transactions to the common 

5 management protocol . 

5. The network element of Claim 1, further 
comprising the first subsystem operable to receive 
management transactions in a Transaction Language One 

10 (TL-1) protocol and to map the transactions to the common 

management protocol . 

6. The network element of Claim 2, further 
comprising : 

15 the first subsystem operable to receive management 

transactions in a Common Management Information Service 
Element (CMISE) protocol and to map the transactions to the 
common management protocol ; 

the second subsystem operable to receive management 

2 0 transactions in a simple network management protocol (SNMP) 

and to map the transactions to the common management 
protocol ; and 

the third subsystem operable to receive management 
transactions in a Transaction Language One (TL-1) protocol 
2 5 and to map the transactions to the common management 

protocol . 

7 . The network element of Claim 1 , wherein the 
dataset is stored in a table format. 
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8. The network element of Claim 1, the common 
management information base (MIB) further comprising: 

a function set; and 

the common interface operable to execute the common 
5 functions to process transactions received from the first 

and second subsystems in the common management protocol . 

9. The network element of Claim 1, the common 
management information base (MIB) further comprising: 

10 a queue operable to store transactions received from 

the first and second subsystems in the common management 
protocol ; and 

the common interface operable to serially process 
transactions from the queue. 

15 

10. The network element of Claim 1, the common 
management information base (MIB) , further comprising: 

a first subsystem queue operable to store responses to 
transactions received from the first subsystem in the 
2 0 common management protocol; 

a second subsystem queue operable to store responses 
to transactions received from the second subsystem in the 
common management protocol ; and 

the common interface operable to generate responses to 
25 transactions and to store each response in the subsystem 

queue of a subsystem from which the transaction was 
- received. 
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11. A method for managing a network element, 
comprising : 

mapping management transactions received in a first 
management protocol to a common management protocol ; 
5 mapping management transactions received in a second 

management protocol to the common management protocol ; 

storing management information in a common dataset; 

and 

accessing the common dataset to process transactions 
10 in the common management protocol. 

12. The method of Claim 11, further comprising 
mapping management transactions received in a third 
management protocol to the common management protocol . 

15 

13. The method of Claim 12, further comprising: 
mapping management transactions received in a Common 
Management Information Service Element (CMISE) protocol to 
the common management protocol ; 

20 mapping management transactions received in a simple 

network management protocol (SNMP) to the common management 
protocol; and 

mapping management transactions received in a 
Transaction Language One (TL-1) protocol to the common 
25 management protocol. 

14. The method of Claim 11, further comprising: 
storing a dataset in a non- volatile memory; and 
accessing the dataset in the non-volatile memory to 

3 0 process transactions in the common management protocol. 
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15. The method of Claim 11 , further comprising: 
storing a common function set; and 

accessing the common function set to process 
transactions received in the common management protocol. 

16. The method of Claim 11, further comprising 
serially processing transactions in the common management 
protocol . 
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